-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Kubernetes] Update namespace filter on data streams #10213
Conversation
/test |
@@ -41,12 +41,6 @@ streams: | |||
multi: false | |||
required: false | |||
show_user: false | |||
- name: namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We needed here and not in the claim right?
See
https://github.com/elastic/beats/pull/39934/files#diff-1d7b17f1ef239e6177db5ee660f2234bfd69c82e93494d4e46ee97f8a8617cfdR285
@@ -43,7 +43,8 @@ streams: | |||
show_user: false | |||
- name: namespace | |||
type: text | |||
title: Namespace to watch resources from for metadata | |||
title: Namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here not needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PVC needs it, PV does not
packages/kubernetes/manifest.yml
Outdated
@@ -10,7 +10,7 @@ categories: | |||
- kubernetes | |||
conditions: | |||
kibana: | |||
version: "^8.14.0" | |||
version: "^8.15.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? This will work for 8.14 as well, with only exception of namespace watcher. But it is not a feature of 8.15.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, but in that case 8.14 already has the namespace filters for most of data streams. I wanted to push for 8.15 to be on track with the other related PRs. Should I fix in 8.14 instead - and maybe remove namespace filter for state_namespace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would require then another PR. I would suggest to keep 8.15 but only merge it after the feature freeze of 8.15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but only merge it after the feature freeze of 8.15
Yes, I agree. I have added a reminder for the day of the release of 8.15, so we won't have to backport in integrations
@@ -60,6 +60,13 @@ streams: | |||
multi: true | |||
required: false | |||
show_user: false | |||
- name: namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we also add namespace
to the top level? similar to the condition
- name: condition |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure. Some data streams have the option node
that I considered at the same level as namespace
, and node
is also not at the top level. Should I change this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to put the namespace filter in each data stream? Can't we put in the group level and check if it applies for all the data streams of the group?
It feels a bit cumbersome for a user to set the namespace value so many times. And a mistake in one of the data streams would break the others as well, because the watchers are shared.
I agree with @MichaelKatsoulis on this regard, that we shouldn't provide the option to set it for each datastream, but on the higher level instead to avoid possible issues, since watchers are shared.
I would split node
and namespace
work and don't touch node
in this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I replied in #10213 (comment).
Do we need to put the namespace filter in each data stream? Can't we put in the group level and check if it applies for all the data streams of the group? About the text Also for this PR to be ready for merge, it should be tested that setting the namespace field does what it supposes to. |
Co-authored-by: Tetiana Kravchenko <[email protected]>
Test for using 1st test
We see that the
The results are still the same as 1. So I don't think the watchers are updated to all namespaces. 2nd test I am restarting the agent. I don't have the The results are as expected. I will now filter by Conclusion: The watchers are only updated when the agent is restarted. |
I have just tried this: With the same tests as #10213 (comment). So it does not work @MichaelKatsoulis @tetianakravchenko. What do you think? |
It seems that having the |
@constanca-m Yes this is tricky and error prone. That is why I believe the way to do this, is to have the namespace option in group level as you tried in #10213 (comment). If you add the namespace in the group level in the
Looking a the files changed in this PR, I don't see any update in the handlebar files? How will the namespace option be passed to the metricsets? For example in state_pod there is already there |
@MichaelKatsoulis I tried setting the namespace per group. I reported the results in #10213 (comment). It does not work, so unfortunately that is not an option. The only way it works is to set the namespace per metricset, which is very prone to errors. |
It wasn't working because you hadn't set the namespace to all hbs files probably. If the namespace var is per group, then the hbs file can read the variable as they already do with condition var. |
I don't think this is it. I tried with |
Thank you @MichaelKatsoulis , this was the problem. I deployed 2 cronjobs in I checked the data from the |
@@ -31,6 +31,13 @@ streams: | |||
required: true | |||
show_user: true | |||
default: true | |||
- name: namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to be more aligned with the rest of the data stream groups, we should also add the namespace option in the central manifest in the events group.
- name: events
title: Kubernetes Event Metrics
This group only contains events data stream but as we do it for the rest, we should be uniform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in the latest commit.
@lucabelluccini I wanted to inform you that with this PR we introduce a small breaking change to Kubernetes Integration. This is actual a fix as the way a parameter was set in the data streams until 1.63.0 version would not work as expected due to changes (for cpu and memory consumption improvements) we have in beats 8.14.0 version. In more details some of the data streams of Kubernetes Integration included a
The problem was that this option even if set, would be overwritten by the other data streams(which did not even had this option), due to the underlying architecture of the metadata enrichment process with kubernetes api watchers mechanism. To tackle this issue, we decided to move the namespace option to the group level of data streams(wherever it makes sense). The breaking change would be that, if a user has a previous version of kubernetes integration where in some data streams the namespace option is set (although not working properly. We really expect very few users to use this), and then decides to upgrade to this new version. This would mean that the namespace option will not be inherited. They will need to set it properly in the group level.
Should we include this information somewhere in order for support to have in mind in an unlike future SDH? |
@constanca-m we should create a follow up issue to check the right place for node option as well. |
🚀 Benchmarks reportTo see the full report comment with |
packages/kubernetes/changelog.yml
Outdated
@@ -1,4 +1,9 @@ | |||
# newer versions go on top | |||
- version: 1.64.0 | |||
changes: | |||
- description: Update namespace filter on data streams |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should be reflected in the description that namespace filter was moved to the group level
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated!
Co-authored-by: Tetiana Kravchenko <[email protected]>
💚 Build Succeeded
History
cc @constanca-m |
Quality Gate passedIssues Measures |
Package kubernetes - 1.64.0 containing this change is available at https://epr.elastic.co/search?package=kubernetes |
* Update namespace filter Co-authored-by: Tetiana Kravchenko <[email protected]> --------- Co-authored-by: Tetiana Kravchenko <[email protected]>
Proposed commit message
Some datastreams have present the
namespace
filter. I will update it to:The namespace filter should be moved to the group level.
Checklist
changelog.yml
file.How to test this PR locally
Related issues
Relates elastic/beats#38978
Results
See #10213 (comment).